Buffering is a common technique deployed in streaming use cases, but it may result in a poor user experience. Buffering is required in the following cases: (1) streaming session start-up (including channel zapping, from one to another one), and (2) jump/seek action initiated by the end user.
An example of a data processing system including a buffer for real-time date is known from U.S. Pat. No. 6,247,072, which discloses apparatus and methods for matching data rates which is useful for a receiver receiving real-time data over a medium. Implementations feature a process establishing a buffer in a receiver; receiving source data from a source having a nominal source data rate, the received source data arriving at an incoming data rate that differs from time-to-time from the nominal source data rate; filling the buffer with source data as it is received at the incoming data rate and emptying the buffer to provide data for consumption in real time at a consumption data rate; setting a rate-matching factor M, the factor M affecting the rate at which the buffer is emptied; and tracking the level of data in the buffer and resetting the value of M to increase the rate at which the buffer is emptied when the buffer fills above a target range, and resetting the value of M to decrease the rate at which the buffer is emptied when the buffer empties below a target range.
Analog media is sampled to be digitalized. This process uses different sample rates depending on audio or video. On one side, audio is commonly sampled from 8 kHz to 48 kHz depending on the use case (<16 kHz for voice content, >16 kHz for music content). On the other side, video may be sampled at 24 Hz by cinema camera, 25 Hz by PAL: European TV standard, about 30 fps by NTSC: US TV standard. During a streaming use case, both the server and the terminal send/consume the media at the same data rate; the server data rate and the rendering data rate are equal and match a real time clock. Cable or terrestrial digital television have constant data throughput, for example the server data rate and the reception data rate are equal. Thus, sent data will be received and rendered by the terminal after a constant delay (transmission time).
FIG. 1 shows a schematic representation of a data processing system according to the prior art. A server S is in charge of sending media to a terminal T via a network N. The server S has real-time behaviour, e.g. it sends media data associated to the server clock. The network N is in charge of carrying data from the server S to the terminal T. A common way to model a network N is to use a buffer B. This buffer B contains data RFS received from the server, and not yet sent to the terminal STT. In this case the network jitter corresponds to the network buffer duration BL. The terminal T—also referred to as “client” or “receiver”—is in charge of receiving and rendering the media from the network N. A terminal T has a media renderer and a buffer AL to manage reception rate variation from the network and consumption rate from the media renderer.
In the context of cable and terrestrial digital television the server sent rate Cs and the terminal reception rate Crec are equal. Thus, both the network N and the terminal buffer AL are constant. Moreover, the sum of these two buffers is about 2 s. Thus, video services have been designed to maximize end-user experience, and thereby the revenues of the broadcaster.
The main end-user insights to have a good end-user experience are: a large number of channels (not addressed by this invention), media rendering must not be interrupted in case of network congestion, quick start up time (˜2 s) (from channel selection to first image display) must be provided, fast zapping time (˜2 s) (from switch command to a new channel, and first image display of the new channel) must be provided and a quick jump/seek time (˜2 s) (from jump/seek command and first image display) must be provided.
In a mobile network the data throughput is not constant, for example the server data rate Cs and the reception data rate Crec are not the same. For instance, when a mobile terminal has a limited network coverage, the server data rate Cs can be higher than the reception data rate Crec. This triggers an increase of the network buffer B and a decrease of the terminal buffer AL decrease (as the consumption rate is constant, equal to the server output rate). Thus, the terminal buffer AL has to support this variation to avoid media rendering interruption, e.g. terminal buffer time to be null.
In order to protect against media rendering interruption, the terminal has to buffer a significant amount of data. For instance, it pauses rendering (rendering data rate Cren is null), and waits for the terminal buffer time to increase. Once the terminal buffer time reaches a threshold, the media rendering starts (rendering data rate equals server data rate). Thus, during this buffering time the playback is paused, and the playback starts again once buffering has finished.
The longer the buffering time, the better protection against bandwidth variation is available. Nevertheless, as the server sends data at real-time, the buffering latency is equal to the end-user latency, e.g. the time elapsing between receiving the first media data and the first image display. This results in a poor end-user experience. In a 2.5G network, a common buffering time is about 8 s. In a 3G network, a common buffering time is about 6 s.
This long buffering time is noticeable in two main use cases: (1) at start-up of the streaming session on a media channel (also when the end-user zaps to another channel), and (2) at jump/seek time. Unfortunately the current situation prevents a massive video streaming adoption by the end-user in mobile networks because the main end-user insights have not been achieved. This poor streaming experience prevents operators to sell and deploy additional value services such as video streaming services, even if they are requested by the end-user. Thus, operators are benchmarking terminal solutions to select the one which does have a minimal terminal buffering time.